docs: OEP-67 automated bundle size checking. #515
Conversation
brian-smith-tcril
force-pushed
the
oep11-bundle-size
branch
2 times, most recently
from
cfcf970
to
a108d20
Compare
brian-smith-tcril
force-pushed
the
oep11-bundle-size
branch
from
a108d20
to
73eae79
Compare
|
|
||
| It is important for users of the Open edX platform that we deliver reasonably sized JavaScript bundles. This provides | ||
| faster load times to all users, and is vital for users with low bandwidth and/or metered connections. To ensure we | ||
| don't unintentionally increase the size of our JavaScript bundles, we should utilize automated bundle size monitoring. |
There was a problem hiding this comment.
It might also be worth a mention that increased observability of bundle size will encourage maintainers to adopt practices such as code/bundle splitting.
There was a problem hiding this comment.
|
|
||
| It is important for users of the Open edX platform that we deliver reasonably sized JavaScript bundles. This provides | ||
| faster load times to all users, and is vital for users with low bandwidth and/or metered connections. To ensure we | ||
| don't unintentionally increase the size of our JavaScript bundles, we should utilize automated bundle size monitoring. |
There was a problem hiding this comment.
[curious] Is it worth mentioning that we have some support for bundle size analytics today insofar that we do generate a bundle size report via the standard Webpack configurations provided by frontend-build which can be viewed locally? E.g., when you run npm run build, a report.html file is generated in the dist directory that lets developers see bundle sizes of JS assets (compressed vs. uncompressed). However, this report is not very discoverable. Exposing similar data via these CI checks makes bundle size a more prominent concern than with the tools Open edX engineers have to work with today.
There was a problem hiding this comment.
I agree it's a good idea to mention it: I myself had totally forgotten about that report!
There was a problem hiding this comment.
| Consequence | ||
| *********** | ||
|
|
||
| `BundleWatch`_ will be adopted by the Open edX community for automatic JavaScript bundle size monitoring. |
There was a problem hiding this comment.
This line feels like it might belong under the "Decision" section?
There was a problem hiding this comment.
| Consequence | ||
| *********** | ||
|
|
||
| `BundleWatch`_ will be adopted by the Open edX community for automatic JavaScript bundle size monitoring. |
There was a problem hiding this comment.
It might also be worth a mention whether it will be up to maintainers / owning squads of repos whether the BundleWatch CI check will be a required status check or not (i.e., informative only versus blocking PRs if exceeding certain threshold). My assumption is that we'd want this CI check to be informative only.
There was a problem hiding this comment.
brian-smith-tcril
force-pushed
the
oep11-bundle-size
branch
from
73eae79
to
9ffa820
Compare
brian-smith-tcril
force-pushed
the
oep11-bundle-size
branch
from
9ffa820
to
63a963e
Compare
brian-smith-tcril
force-pushed
the
oep11-bundle-size
branch
2 times, most recently
from
368419e
to
6e4ca35
Compare
brian-smith-tcril
changed the title
feanil
changed the title
feanil
force-pushed
the
oep11-bundle-size
branch
from
6e4ca35
to
f0beece
Compare
No description provided.